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System entr y /exit - Operation Inte raction 

Control passes from the user to the entry point (USERCAL) of the system 
entry/exit routines when the user executes a CEJ instruction. Control 
returns to the user (at S.RETU) at the end of the system entry/exit routines, 
again by a CEJ instruction. Thus the system runs in monitor mode, while 
the user runs in user mode. The function of these routines is to determine 
the reason for the user's call upon the system (i.e., the operation he wishes 
to perform), to collect and check the parameters needed for the operation, 
to transfer control to the proper system action routine specified by the 

n-n j~^-^ ^ *• A n-n r^v\ A *• fi Kt.^^1#-i t-VuTi v*Ql-iivt-» t- /^ ^-Vici M c? ^ tr n ^ f- ^ IT i-Viii OXTO^ am '^ n f" "i nuTt TO 

completed. 

Operations are ECS system objects which control the calling of system actions 
or subprocess call actions, and provide the mechanism to facilitate "layers" 
in the system. Internally, an operation consists of one or more orders, 
each in the same format, prefixed by a fixed sized header. Each order 
specifies an action and consists of an action number, which is an index 
in a jump table of ECS action addresses; parameter information, which is 
used by the system entry/exit routines as explained below; and those para- 
meters for the action(s) of the operation which are fixed for each call 
(see Figure 1). 

The parameter information consists of a variable-length sequence of bytes, 
one for each parameter to indicate its type. The parameter specification 
types and their descriptions follow: 

PS.UCAP user-supplied capability (which must match the type and 
option bits stored in the operation) 

PS.UDAT user-supplied 60-bit datum (no checks are performed) 

PS.FCAP fixed capability (both words of a capability are stored in 

the operation, and no corresponding information is taken from 
the user's input parameter list) 

PS.FDAT fixed datum (a 60-bit data jord is stored in the operation, 
and always passed unchanged) 

PS.ACAP any capability (a capability is expected from the user, but 
no type or option checking is to be performed on it) 
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PS. NONE none (when an operation is created; all parameter specifi- 
cations are initialized to "none", but they must be fixed 
with the various actions supplied before the operation may 
be used "^ * 

A bit in the operation is set if the action involved is parameterless ; in 
this case there are no parameter specification bytes. W?ien present, the 
3-bit parameter specification bytes ar-(» packed 19 to a word, with special 
bytes to indicate "end of current byte-word" and "end of all bytes". Fol- 
lowing the byte-words come the parameter specification data-words: a word 
containing option bits and a capability type for PS.UCAP parameter specifi- 
cations, and the fixed parameter (a two word capability for PS.FCAP bytes, 
a 60-bit datum for PD.FDAT bytes), but nothing for any other type of para- 
meter specifications. If the action specified by the operation is a "sub- 
process call" or "jump-call", a flag bit in the operation indicates the 
presence of a class code (name of the subprocess to be called), and the 
class code will appear after the data words in the operation. 

In addition to the above mentioned information, each order of an operation 
contains several fields used to "traverse" the operation when it is being 
interpreted or changed. There is a total-number-of-parameters field, which 
is cumulative for all orders from the first through the current order, as 
well as a cumulative-total-nuraber-of-capability-parameters field. Also, 
each order contains the length and origin (relative to the beginning of 
the operation) of the next order. 

At system initialization time, operations for all available ECS system. 
actions are created. In addition, operations may also be created for par- 
ticular subprocess calls or jumps. The user of the TSS may call upon any 
of the system action operations for which he has been given a capability. 
The system actions created at initialization allow the user to create 
and manipulate ECS objects, e.g., create, read and write files, and 
create subprocess call or jump operations etc. (See individual documents 
and below for details.) 

On entry to the system entry/exit rouuiues (at USEKCAL) the origin of the 
process descriptor (see Proro:;seK) Ims l^en picked up in Bl by the exchange 
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jump. The origin of the process descriptor will remain in Bl through 
all system actions. First, the system and user clocks are updated. The 
difference between S.OLDTM, which contains the value of S.CHARG from the 
last time it was updated, and S.CHARG, which runs whenever the interrupt 
system is not running, is added to the system total user time (S.URSTM) in 
system core and to the user's total user time (P.USRTM) in the process 
descriptor. 

The CEJ instruction which caused the transfer of control is then examined 
to find the address of an input parameter list (see Figure 2). It is ex- 
pected that the CEJ which the user executed was in the upper two parcels 
of the instruction word. The low order 18 bits of the 30 bit CEJ instruc- 
tion are extracted and interpreted to locate an input parameter list. If 
the 18 bit field is negative, the complement of the low order 4 bits spe- 
cify which register in the user's exchange package contains the input para- 
meter list (IP list) pointer (e.g., -3 -^ B3; -10 -*■ X2). Otherwise, the 18 
bit field is taken to be the IP lict pointer. This pointer is checked for 
legality (i.e., must be positive and less than user FL) and an error is 
generated if necessary. Finally, the IP list pointer is saved in the pro- 
cess descriptor at P.IPLIST in case it is needed to form a stack entry for 
a subprocess call. Also the stack manipulation flag (P.OLDP), which con- 
trols the updating of the old stack entry in case of a subprocess call, is 
reset. 

Next, the first word of the IP list (called IPO) is expected to be, and is 
interpreted as, a full C-list index of the operation for the desired action. 
The corresponding capability is fetched by calling GETCAP (note that a nega- 
tive or overly large C-list index will cause an error to be generated). This 
capability is checked to insure that it is a capability for an operation; if 
it is not, an error is generated. The first order of the operation is read 
from ECS by reading the fixed-sized header and then reading in the first 
order. 

The parameter specifications of the first (and possible only) order of the 
operation are used by OPINTER to torm an actual parameter (AP) list in the 
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process descriptor starting at P.PARAM. This list consists of the two 
actual words of each capability parameter and one word for each datum 
parameter. Parameters which are fixed in the operation are copied 
directly to the actual parameter list. User supplied parameters are 
drawn from the IP list, which is expected to contain in successive words, 
C-list indices and data parameters. C-list indices are checked to assure 
that they fall in the range of the full C-list and are used to fetch the 
actual two words of user-auppxieu t-Hp-^nilitxtii} . User-supplied capabilities 
are checked for the correct type and required options unless the parameter 
specification is "any capability". User-supplied datum parameters are 
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If a "none" parameter specxf ication is encountered, an error is generated 
and parameter processing is terminated. 

For operations which are flagged as being parameterless, the interpretation 
of parameter specifications is omitted. After the completion of the actual 
parameter list (AP list), the operation is checked to see if it requires a 
subprocess name and parameter type bit masks (i.e., it is a subprocess call 
operation). If so, the subprocess aatne is copied from the operation to 
P.PARAMC in the process descriptor, t^;e number of parameters is stored in 
P.PARAMC-1. In addition, the input-parameter list address is stored in 
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Stack entry. 

Finally, the ECS action number is extracted from the operation; it is used 
as an index to jump into the ECS action jump table starting at ACTIONL 
where there will be a jump to the proper entry point for the desired action. 

Upon successful completion of an KCS action, the ECS action routine normally 
returns to the system entry/exit routine to return control to the user. The 
only exceptions to this are the case in which the user process has hung on 
an event channel or exceeded its quantum, in which case the event channel 
routine exits to the swapper, and the case In which an F-return has been 
made. An F-return results Xv'hen a situation arises which is not serious 
enough to cause an error but does not permit the action to be carried out 
normally . 
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There are three points in the system return sequence to which an ECS 
action may return: SYSRET, TOUSER and S.RETU. The normal return begins 
at SYSRET. This return updates the user's P-counter in accordance with 
the user supplied P-counter offset which is stored in the low order 18 
bits of the CEJ instruction word originally used to call the system. 
The legitimacy of the new P-counter (old P-counter + P-counter offset) is 
checked and an error may be generated. Falling through to TOUSER the 
normal return updates the systeit tLue clocks at S.SYSTM in system core 
and P.SYSTIM in the process data area and checks to see if the user's 
quantum has run out. If S. QUANT is positive (quantum has run out) the 
Rwarsnpr is entered at SWAPOUT= Otherr-^ise an exchan'^e '■um'^ '^CEJ^ is exe- 
cuted at S.RETU to return control to the user. 

If an F-return results, either from a subprocess call action or an ECS 
action, control transfers to SYSFRET, and the IP list whose address is the 
top entry of the stack or P.IPLIST is consulted. The count of the number 
of orders in the operation, kept in the header word, is checked and if re- 
maining orders exist, the F-return count in the stack is incremented, and 
the next order of the operation is interpreted. This proceeds as previously 
described, except that the parameter specification of all orders up to and 
including the current one are used to form the actual parameter list. If 
any one of the subsequent orders terminates normally, the return is through 
SYSRET as described above. If the F-return count reaches the number of 
orders in the operation, then the return is to TOUSER and behaves the same 
as the return to SYSRET except that the user's P-counter is not modified. 
(This return is used by the subprocess calling, subprocess return and 
process interrupt action routines.) 

If the action resulted in an error, control transfers to E. ERROR where 
error processing, which involves calling a subprocess in the user's process 
to handle the error, is initiated. (See Subprocesses. ) 

The entry S.RETU is used by the swapper after a process has been swapped 
in to transfer control to the user; it consists only of the CEJ instruc- 
tion. 
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Creating an Operation 

When an operation is created, each of its parameter specifications is 
initialized to "none", and the operation thus may not be invoked (unless 
it is parameterless) . There are two actions for creating new operations. 
The first creates an operation of order 1 to call or jump-call a designated 
subprocess. The secoiiJ .iCLion ci\:.-. lc:-; sn oper.-Jtion of order N. It is 
supplied with an operation of order N-1, which is copied with a new order 
appended, again to call or jump-call a named subprocess. 

ECS system actions are also available to copy an existing operation and 
then to modify the parameter specifications as well as to destroy an 
operation. 

In order to specify the parameter specifications in an order of an opera- 
tion created in any of the ways just described, a set of actions is 
provided. Each takes as parameters an operation, a parameter specification 
index (for which purpose the order-boundaries of the operation are ignored), 
and further information in certain cases. The actions are 

ACAP change a PS. NONE to a PS.ACAP specification (no further 
parameters need be supplied) 

UDAT change a PS. NONE to a PS.UDAT specification (no further 

UCAP change a PS. NONE to a PS.UCAP specification (two additional 
parameters are required, a type and an option bit mask) 

FDAT change a PS.UDAT to a PS.FDAT specification (an additional 
parameter, a 60-bit datum, is required) 

FCAP change a PS.UCAP to a PS.FCAP specification (an additional 
parameter, a capability index, is required) 

Note in the last two cases that "fixing" a parameter specification requires 
two steps, changing the specification first to a user-supplied type and then 
to the corresponding fixed type. 

The UCAP, FUAT, and FCAP actions involve reallocating the operation in ECS, 
since in each case one extra word is added to an order of the operation. 
Also, the cumulative-total-of-capability-parameters field must be updated in 
the affected order, and ail fields after it, in the case of the UCAP and 
FCAP actions. 



System entry/exit - Operation Ineraction 

Figure 1 
Operation 



First 
order 



1st bit — 

Action type: 

20„ == subprucess 
call or 
J unip 

■~8 ■:" ~": 

less action 



Second 
order 



LENGTH OF 
1st ORDER 

lUIMfipriTI 



NUMBER 
OF ORDERS 



llijjlijliii 



IPtr to 1: 
JPS DATUM 






' r.iJH CNT OF 
j CAPABILITY 

j P AKAMS 

i 



CUM CNT 
OF 
i PARAMS 



Length of ; Origin of Action // 



!M<jvf Ctrr^ar- 



I f'r 19 






i i 



Action Type 



PTR to 1st 

P.q nATTIM 



ixLJ 



Operation 
header word 
Parameter type 
bit mask 



li 



Parameter Specifi- 
cation Bytes 

^ (Length in words: 
(J\ of params this 

, order)/20 



Parameter specifi- 
cation data words 
'\ \ (one for each 

PS.UCAP and PS.FDAT; 
two for each PS.FCAP) 



4— Class code (present 
J only for subprocess 
call or jump) 



system entry/ exit - uperation interaction 



Figure 1 - Operations (con't) 
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ALLOCATION OF ECS 

The lower portion of ECS contains system code and certain other specialized 
system cells. The remainder of ECS is divided into blocks of three varie- 
ties: objects, free blocks, and file blocks. 

The Master Object Table (MOT) is located in low ECS and contains an entry 
for each object in ECS (see Figure 1). Each entry occupies one cell and 
contains a pointer to the object ar; .v't: 1. 1 as the "nm'nne name" associated 
with the object. Except for the special case of "direct access" all refer- 
ences to an object are made through the MOT entry. The unique name must be 
^'■'>->-'^"-" .jgcij-iio I. ci uiij,4ut; iiciuic- piuvxueu uy uiit; ut>ei xn iixs capaoxxxcy 
before allowing access to the object. This insures protection even after 
an object has been deleted and the MOT entry has been reassigned. The 
pointer in the MOT enables the relocation of objects during garbage 
collection. 

The unused entries in the MOT are linked in an "available space list", to which 
a pointer is maintained in ECS at EC.ABPCK. The next available "unique 
name", issued serially, is kept at EC.ABPCK+1. A system disaster occurs 
when the MOT "available space list" is exhausted or the next available 
unique name exceeds 2^^ - 1. 

Objects are the true residents of ECS and are classified as: Allocation 
Blocks, Capability Lists, Event Channels, Files, Operations, or Processes. 
Each of these occupies one block except files, which constitute a tree 
structure of blocks. The root of this tree is the file descriptor, the 
actual object. The leaf nodes (data blocks) and the other nodes (pointer 
blocks) are classified jointly as file blocks. Each file block is located 
by a single pointer, guaranteeing ease of relocation for file blocks as 
well as objects. 

Each continuous portion of unused space in ECS forms a free block, which 
is linked into a two-way circular J.ist. Pointers to this, the Free Chain , 
are maintained in two cells at EC.APACK. (See Figure 2.) 
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Allocation Bl ocks 

The Allocation block is the object which regulates ECS allocation and 
CPU usage. An Allocation block can be provided with a sum of money and 
a portion of ECS space, which can only be obtained from another alloca- 
tion block. Every object is associated with an allocation block; these 
objects are linked to the allocation block in a two-way circular list. 
The allocation block heads this list, and each object has a backpointer 

*- ^ -: *- « rt 1 1 « « rt ^- -; «*^ "Ui^rtix T^Viz-i ^"k -4 /^ ^ 4-f-. ^^ Trr'C *-Vt^-v^-F^-»-^ -P^-v-m o t->-r^/^ 

The root of this tree is the Master Allocation Block which is created at 
initialization and provided with an infinite amount of money, and all of 
ECS. 

The allocation block will be billed for CPU-time used by its descendant 
processes, and will be charged rent on the ECS space occupied by its 
descendant objects. FUND is the routine which charges this rent and must be 
called whenever the size of a descendant object is to be changed. It must 
also be called periodically to prevent deficit spending. As of this writing, 
policy decisions are pending regarding allocation blocks (e.g., what to do 
if an allocation block runs out of money). 

FUND is called with an allocation block, and an increment to ECS space. 
It compares the master (S.MASTR) clock with the "time of last bill" field, 
updating the latter, and charging rent for the interim on ECS space in use. 
"ECS in use" and "$ used for rent" are updated. "ECS in use" cannot exceed 
"Allocated ECS" and "$ used" cannot exceed "$". (See Figure 3.) 

FUND has three entry points: 



FUND - B2 
B3 
X5 

FUNDX7 - B3 
X5 
X7 

FUNDB - B3 
A0 
X0 
X7 



Increment to ECS space 

Return link 

2nd word of capability for alloc bk 

Return link 

2nd word of capab. for alloc bk 

increment to ECS space 

Return link 

S.ABLOCK 

ECS address of alloc bk 

increment to ECS space 
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Block Manipulation 

At system initialization time the following blocks are created: the 
Master Allocation Block, two zero-length free blocks, and several free 
blocks (max. size =2*^-1) consisting of the rest of ECS. After that, 
block structure of ECS is in the hands of four routines: 

ALLOC creates a block, of specified size 

The free chain is scanned for a block of sufficient size. If 
none is found, a garbage collection (GBGCOLL) is called. Other- 
wise, a determination is made whether the free block is suffi- 
ciently larger than the requested size to justify splitting it 
up. If so, the new block is taken off the beginning of the free 
block, whose size field is updated. it not, the entire block is 
used and is removed from the free chain. The allocator's word is 
written and a pointer to the block is stored at a caller-specified 
cell. Finally, the block is zeroed. 

On entry: B2 - size of block 

B3 - type of block (l=pointer block; 0=data block or object) 

B7 - return link 

X5 - ECS address of pointer tc be set. 

REALLOC changes the size of a block (always an object) 

First it is determined if a new block will be required (it will 
not be if the increment is negative or less than the slop). If 
not, FUND is called with the increment, and the "size in use" 
field is updated. Otherwise, FUND is called with the total size 
of the new block, and ALLOC is called to find the block. FUND 
is again called to defund the original block (without this double 
call, a system diaster would occur if ECS were saturated). The 
contents are transferred from old block to new, FREE is called 
to release the old block, and the pointer in the MOT entry is 
updated. 

On entry: XI - increment 

X2 - MOT index of object 
X6 - return link 

FREE inserts a block into rhe free chain 

The block is merge.^ with eithtr or both adjacent blocks when 
they are free. Th- ,)r inter to t?>e block is zeroed. 

On entry: B7 - ...lu,:u link 

X5 - ECS address of pointer 

GBGCOLL , when written, will compact the block structure. 
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Object Creation and Destruction 
MAKEQBJ creates an object 

FUND is called; an MOT entry is created; ALLOC is called. A 
capability for the object (all option bits set) is created and 
stored in "CAPAB". The list associated with the father alloc bk. 
is updated (the header word is written) . 

On p-ntrv : R? — ci ■yo nf /->K-iq^<- t-n U^ ^v.««4-^j 

B4 - return link 

X5 - 2nd word of capability for alloc bk (father) 

X7 - type of object 

On exit: X5 - address of first usable word 

DELOBJ destroys an object 

The father allocation block is found, and the object is removed 
from its list. FUND is called to defund the space; FREE to 
release it. The MOT entry is added to the MOT free list. 

On entry: B7 - return link 

X5 - 2nd word of capability for object to be deleted 

File Block Creation and Desctruction 

MAKEFIL creates a file block 

It calls FUND and ALLOC only. 

On entry: B6 - type of block (1 - ptr blk; - data blk) 
B7 - return link 

X5 - 2nd word of capab. for alloc bk. 

X6 - ECS address of ptr to new block 

RTRNF IL deletes a file block 

It calls FUND and FREE. 

On entry: B7 - return link 

X5 - 2nd word of capab for alloc bk 
X6 - ECS address of pointer 
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Miscellaneous Routines 



Four ECS actions: 



NEWUN changes a unique name 

This is the system "Indian-giver" 

API = D : C-List Index of Object whose unique name 
is to be changed . 

CREALBK creates an allocation block. 

API = C : Father alloc bk 

AP2 = D : Index for new capability 

CCCLQA constructs a capability (all option bits set) for the 
newest-born child of the alloc bk. 

API = C : Allocation block 

AP2 = D : Index for new capability 

DONATE transfers space and money from one alloc bk to another 

API = C : Alloc Bk (DONOR) 

AP2 = C : Alloc Bk (DONEE) 

AP3 = D : ECS space to be transferred 

AP4 = D ; Money to be transferred 
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Figure 1 MOT entry 
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Figure 2 
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Figure 3 Allocation Block 
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Capabilities and Capability-Lists 

User access to all objects within the ECS system is controlled by capabilities . 
A capability identifies the object it refers to, specifies the type of the 
object, and the set of allowed actions on that object (options). Capabilities 
are grouped together in capability-lists (C-lists) which are themselves objects 
within the ECS system. Individual capabilities are referred to by their index 
witliin a C-lisL. Since the capability, residing in a (J-list, authorizes access 
to an object, tlie user is never allowed to fabricate a capability. The system 
creates a capability witli nil options allowed when an object is created. Sys- 
tem actions are provided to permit the user to examine a capability, to copy 
capabilities between C-lists and within a C-list, and to downgrade the option 
mask (see System Actions). Thus, the user can transfer the right to access an 
object and can curtail that access, but he may never manufacture that right or 
increase the set of allowable actions on the object. 

CAPAB ILITY 

A capability consists of two 60-bit words (see Figure 1). The first word con- 
tains the type of the object to which the capability refers and a bit mask 
indicating the allowed actions on the object. The type field occupies the 
lower order 18 bits of the first word and must- ha 



\TC d-vr^n 
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set to allow the testing of options and type bits with one instruction (the 
implication function). The remaining 42 bits comprise the option mask. The 
meaning of the bits in the option mask, of course, depends on the type of the 
object. 

The second word contains the information necessary for the ECS system to 

access the object (or, in the case of a class code, the object itself). 

The system uses the low order 18 bits of the second word, which contain the 

master object table (M0T) index, and the high order 39 bits, which contain 

the unique name of the object. The remaining 3 bits of the second word are unused. 

Capabilities are created by the allocation routines at the point when storage 
is allocated for a new object. The new capability with all options allowed 
is placed at CAPAB and CAPAli+1 by rtu' n I location routines. The rnutini- 
crealing tlie new object then moves lo.v ••,'pability to its user-des i jMi.;r < ri 
position in the user's full C-list by caiJing PUTCAP. 
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A capability list (C-list) is a sequence of capabilities and "empty" posi- 
tions (see Figure 2). It is prefixed by the total number of spaces for 
capabilities. "Empty" positions are simply two zero words. Each C-list is 
filled with "empties" upon creation. 

A C-list is assigned to every subprocess within a process. (See Figure 4). For 
every process there is defined a sequence of subprocesses called the full path . Cor- 
responding to the full path, the full C-list is defined as the concatenation 
of the C-lists belonging to the subprocesses in the full path. When referring 
to capabilities within the full C-list, the capability index is interpreted 
as if the C-lists in the full C-list have been joined to form one long C-list. 

The full C-list is implemented by maintaining a full C-list table within the 
process descriptor (see Figure 3). The full C-list table is a sequence of two 
word entries each of which identifies a C-list and the length of the C-list. 
P.CLIST in the process descriptor holds a pointer (relative to the origin of 
the process descriptor) to the first entry in the full C-llst table. The full 
C-list table is terminated by a zero word. The first C-list (called 
-he local C-llst ) in the full C-list is copied into core with the process while 
the remaining C-lists remain in ECS. P.CTABLE, in the process descriptor, 
holds a pointer to the end of the full C-list table (the zero word), the number 
of entries allowed in the table (maximum length of the full path), and the 
size of the core buffer for the local C-list (maximum local C-list size). 

Three routines are used to access C-lists. GETCAP is used to fetch a 
capability from the full C-list. PUTCAP copies a capability to the full 
C-list. If the capability falls within the local C-list, it is copied to both 
the ECS copy and the in-core copy of the local C-list. Finally, ARBCAP 
is used to copy a capability to or from an arbitrary C-list (not the full 
C-llst). 
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Fi les 



A file is an ECS system object, containing a sequence of addressable 
(60 bit) words, used to provide storage for code and data. In order to 
permit a large file address space and, at the same time, make efficient 
use of ECS space, ECS files are organized in a tree structure. The 
"leaves" of the file tree are called data blocks and contain the 
addressable words of the file. The non-terminal nodes of the file 
tree are called pointer blocks (see Fig. 3) and contain links to either 
data blocks or other pointer blocks. With this tree structure, only the 
necessary pointer blocks and data blocks are allocated in ECS. Empty or 
non-existent portions of the file are not allocated until they are needed. 



For any file, there is a sequence of positive integers, (S^,S ,...,S ) 

n >^ 0, which describe the shape of the file. Each S., for £ i < n, is 

the number of branches in the file tree at nodes of level i (the root of 

the tree is at level 0; all nodes connected to the root are at level 1; 

etc.). Each S. for i > 0, must be an integral power of 2 (note: this 

does not apply to the first shape number S„ ). The last shape number, 

S , is the size of the data blocks. Thus, the number of addressable words 

n 
in a file is given by L = .n„ S. . The words of a file are addressed by 

integers which may range from to L-1 . 



The shape of a file is represented by the dope vector for the file 
and is stored in the fiij descriptor (see Fig. 2 ). The file descriptor 
is pointed to from the master object table (MOT). It contains the dope 
vector, the length of the file, a pointer to either a pointer block or a 
data block (zero level file), and the MOT index and unique name of the 
Allocation block which funds any changes in the ECS space occupied by 
the file. The dope vector contains instructions which are executed to 
obtain the path through the file tree which leads to a particular address 
within the file. When a file is created, only the file descriptor is 
constructed, and the file may be destroyed only when it is in this state. 
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fo inter blocks (Fig. 3) link the file descriptor to the data blocks in all 
files with more than one shape number (n > 0). Pointer blocks are con- 
structed only when needed to link to data blocks. The allocation infor- 
mation wliich prefixes each block in ECS is used to provide a return path 
through the file tree. This backpointer contains the absolute ECS address 
of the single word which points to the pointer block (in the file descriptor 
or in a pointer block at the preceding level). A count of non-empty pointers 
within the pointer block is also maintained in the allocation prefix to 
the pointer block (note: the counter is greater than 0; otherwise, the 
pointer block is not needed). The word following the last pointer in the 
pointer block contains a negative number which is a relative pointer to 
the first word of the allocation prefix. 

Data blocks (Fig. 4) contain the addressable words of the file. 
The count of maps (see Maps) which reference the data block is maintained 
in the second of the allocation words. 



File actions 

When a file is created, only the file descriptor is formed. Data 
blocks may be subsequently added, one at a time, to hold data or procedures. 
When a data block is added to a file, it may also be necessary to create 
some or all of the pointer blocks between that data block and the file 
descriptor. Data blocks may also be removed and, again, one or more pointer 
blocks may be deleted if they are no longer needed to link to the remaining 
blocks in the file. A data block may not be deleted if it is referenced by 
an entry in some subprocess map (reference count / 0). 

Files may be read and written . This action transfers words between the 
address space of the running subprocess and the data blocks of a file. If 
a transfer is requested which involves a file address corresponding to a 
non-existent data block, the transfer proceeds until the non-existent file 
address is encountered and then an FRETURN is initiated. 
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Processes 



Processes are the active elements of the ECS portion of the time sharing 
system. Only within the context of a process may code be executed and 
system actions initiated. A process consists of a set of central regis- 
ters (exchange jump package) , a set of s ubpro cesses organized in a tree 
structure, a call stack recording the flow of control among the sub- 
processes, and a set of state flags describing the state of the process. 

Swapping : Periodically, a process with its running flag set (see below) 
will be swapped into CM to run on the CPU. When this occurs, the process 
descriptor and local C-list are read in, and the entries in the full pro- 
cess map are swapped in from the indicated files in ECS to the Indicated 
regions in CM. The exchange jump package of the process is loaded into 
the central registers of the CPU and the CPU is allowed to compute for 
awhile or until the process hangs. Then the central registers of the 
CPU are copied to the exchange jump package of the process, and the process 
is swapped out. 

Process Descriptor 

The data necessary to maintain and run a process are gathered together in 
the process descriptor, which is stored in two sections: the fixed length 
process descriptor and the variable length process descriptor. These two 
sections of the process descriptor are copied into CM when the process is 
being run on the CPU. While the process resides in ECS (See Figure 1), the 
fixed length descriptor and variable length descriptor are separated by 
the process queuing word buffer (see Event Channels). Information about 
the size of the queuing word buffer is contained in the first word of the 
process descriptor (P.ROHEAD). Data necessary to access and move the 
variable length descriptor are contained in the second word of the process 
descriptor (P.ROHEAD +1). 

When the process descriptor is copied to CM to run the process on the CPU 
(see Figure 2), it is preceded by a scratch area (used by the system while 
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performing system calls) and the actual parameter area used to pass the 
parameters of system calls (P.PARAM). In addition, the local C-llst 
is copied to CM following the fixed length descriptor and preceding 
the variable length descriptor. All pointers within the process 
descriptor are computed relative to the beginning of the scratch area. The 
absolute CM address of the scratch area is maintained by the system in 
S.USRBl in system core and in Bl of the system exchange package. 

The fixed length process descriptor is divided into the read only descriptor 
and the read write descriptor. The read only descriptor may not be modi- 
fied without lockinc' out the PPU interruDt system (I.LOCK). it contains 
(see Figure 3) the state flags of the process, process interrupt information, 
and process scheduling data. The read/write portion of the fixed length 
descriptor contains the process exchange jump package, data and pointers 
used to access and modify the variable length descriptor, and a few words 
of global process data. 

The variable length process descriptor (see Figure 4) contains the full 
C-list table, the call stack, the subprocess descriptor table, logical map 
and error selection mask (ESM) storage, and compiled map storage. Organiza- 
tion of the variable length descriptor is maintained by pointers and values 
in the fixed length descriptor. When the process is in CM running on the 
CPU, the variable length descriptor is separated from the fixed length 
descriptor by the local C-list buffer, which is large enough to contain 
the largest C-list assigned to any subprocess in the process. Both the 
call stack and subprocess descriptors contain pointers into the variable 
length descriptor. These pointers, like those in the fixed length des- 
criptor, are relative to the origin of the process scratch area (P. SCR). 
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Eight flags describe the state of the process. These state flags , stored 
in P.ROHEAD (see Figure 3), are used primarily to control the swapper, 
but are set and chocked by other routines (event channel, process inter- 
rupt, and destroy process). Since the state flags are used to indicate 
the "state" of the process, they must never be modified without the FPU 
interrupts first being locked out to prevent 'test and set' overlaps. 

The eight flags function as follows : 

The E flag indicates that the process is actually a pseudo-process and 
is used by the event channel routines to distinguish 
between genuine and pseudo-processes. 

The "in core" flag, C, is set whenever the process is actually run- 
ning on the CPU. This flag is checked by the process 
interrupt routine. 

The "pending action" flag, P, directs the swapper to interrogate 
the "W", "1", "D" and "V" flags. These four flags 
cause the swapper to: 

W - (the wakeup waiting flag) unchain the process flow from the 
event channels; 

I - check the "ancestors" of the current subprocess for an inter- 
rupt subprocess; 

D - destroy the process; and 

V - modify the swapper return because of the arrival of an event 
for the process. 

The "running flag", R, indicates that the process is scheduled to run 

or is running on the CPU. The running flag (R) and 

the wake-up waiting f]ag (I/) irr.e.ract in the event 

channel routines as well as in the process interrupt 

routines. They are used to permit the process to 

"hang" on several event channels and still be able to 

accept an incoming event. 
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SUBPROCESS TREE AND FULL PATH 



The subprocess tree is organized so that each subprocess references only 
its predecessor (see Figure 5). For each subprocess, the term "ancestors" 
refers to the sequence of subprocesses which starts with the subprocess 
and terTninates with the root of the subprocess tree. Note that a sub- 
process is always an "ancestor" of itself. At any given time, there are 
two distinguished subprocesses within the process. They are known as 
the current subprocess and the end-of -path subprocess. The current sub- 
process is always an "ancestor" of the end-of-path subprocess; the sequence 
of subprocesses from the end-of-path to the current subprocess (inclusive) 
is called the full path . The end-of-path is defined dynamically by the 
flow of control among the subprocesses. The current subp rocess may be 
considered to be the subprocess currently in control. The end-of-path and 
current subprocesses are reassigned whenever a new subprocess is called. 
The subprocess being called (the callee ) becomes the new current subprocess. 
If the callee is an "ancestor" of the old end-of-path, then the end-of-path 
remains unchanged. If the callee is not an "ancestor" of the end-of-path, 
the new end-of-path becomes the same as the callee (i.e., the full path 
consists of a single subprocess - the callee). See Figure 5a. 

The full path defines the sphere of protection invoked by the current sub- 
process. The access into the current subprocess permitted to other objects 
within the system is controlled by the full C~list. The full map determines 
the configuration of the address space available to the current subprocess, 
and the full address space is the size of the address space available to 
the current subprocess. The full C-list, full map, and full address space 
are defined by the full path. The configuration of the subprocess tree defines 
the static relationship between the subprocesses (subprocesses closer to 
the root may be given the privileges of their descendents) while the full 
path dynamically controls the boundaries of access applied to the current 
subprocess. This system of controlling the bounds of protection allows 
the construction of processes which may exercise varying degrees of pro- 
tection while maintaining synchronization between the subprocesses involved. 
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CALL STACK 

The call stack records the flow of control among the subprocesses . It 
contains the information necessary to reactivate a subprocess when con- 
trol returns to the subprocess after one or more subprocess calls. Each 
stack entry is two words long (see Figure 6). The current subprocess, 
the end-of-path subprocess, and the P-counter must be saved at the time 
of the subprocess call to reconstruct the full path and to re-initiate 
processing where it was terminated by the subprocess call. The address 
(within the full address space of the subprocess) of the input parameter 
list fspp Svsfem Kntrv/Kxi t ") used for the last- svs^pm rpl 1 i ni t"i3tPfi hv 
the subprocess, and the count of orders processed in the operation used 
in the last system call are retained to enable processing of F~returns. 
Finally, three flags arc used to control the return of control to 
a subprocess. The "interrupted" flag indicates that the subprocess 
was interrupted and that the P-counter is not to be modified in 
the usual way (see System Entry/Exit). The "forced F-return" flag indi- 
cates that F-return action had been interrupted and instead of returning 
to the current subprocess, F return action should be initiated. Finally, 
an "inhibit interrupt" flag is used by the interrupt machinery to inhibit 
the interruption of the current subprocess by itself. P. STACK is used to 
control the call stack and contains the stack origin, stack end, and top 
of stack pointers relative to the incore process descriptor. The P-counter 
and input parameter list address in the top of the stack are not always 
maintained since the P-counter is in the process exchange package (P.XPACK) 
and the last IP list address is maintained in P.IPLIST. Each subprocess 
is assigned a maximum stack pointer value to prevent the stack from being 
filled to such an extent that the subprocesses closest to the root of the 
subprocess tree cannot be called to rectify the situation or to handle 
errors . 
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The use of improper parameters in making an ECS system call is detected by 
the ECS system and is considered to be an error on the part of the pro- 
cess making the system call. The process must be informed of the exis- 
tence and type of the error and in addition is given some control over 
which subprocess is to handle the error condition. 

Associated with each error detected by tlie ECS system is an error clas s and 
^" ^£9S. number . Furthermore, associated with each subprocess is an error 
selection mask (ESM) (see Figure 7) indicating which classes of errors the 
subprocess is prepared to handle. 

When an error is detected, it is first assigned an error class and error 
number. Then the "ancestors" of the current subprocess are checked (starting 
with the current subprocess) to find a subprocess whose ESM indicates it 
is willing to handle this class of errors. Finally, the subprocess which 
accepts the error is called, and is passed the error class and number as 
parameters of the call. In addition, in the ESM of the subprocess which 
accepts the error, the bit corresponding to the error class of the error 
is turned off to avoid error loops (i.e., a subprocess makes an error, 
accepts the handling of the error, and makes the same error). 
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ERROR PROCESSING AND PROCESS INTERRUPT 
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PROCESS INTERRUPT 

Two mechanisms are available by which one process may affect the execution 
of another process: the event channel, used to synchronize otherwise 
asynchronous processes; and the process interrupt, used by one process to 
force the calling of a specified subprocess (called the interrupt subprocess ) 
within another process (called the interrupted process ). Thus one process 
can force a second process to enter a specified subprocess. Furthermore, 
the interrupted process will not enter the interrupt subprocess until the 
interrupt subprocess is an "ancestor" of the current subprocess. In this 
way, the interrupt is given a "priority" based upon the position of the 
interrupt subprocess in the subprocess tree of the interrupt process. 
With the process interrupt, an 18-bit interrupt datu m is passed as the 
parameter of the call of the interrupt subprocess. Once a subprocess 
becomes an interrupt subprocess, and until that subprocess has been called 
as an interrupt subprocess, interrupts to that subprocess are disabled 
(i.e., additional interrupts specifying that subprocess have no effect). 
It is also possible to disarm interrupts which are the same as the current 
subprocess (recall that the current subprocess is an "ancestor" of itself 
and thus could interrupt itself). When an interrupt subprocess is called, 
interrupts are automatically disarmed for the current (= interrupt) subprocess. 

If the interrupted process is "hung" when a process interrupt is initiated, 
the "ancestors" of the current subprocess (in the interrupted process) are 
scanned to see if the interrupt subprocess is among them. If the inter- 
rupt subprocess has "priority" over the current subprocess, the "wake-up 
waiting", "running", and "interrupt" flags are set in the interrupted 
process and the process is scheduled to run. 

At every normal subprocess call and return, the number of pending inter- 
rupt subprocesses (P.INTERR) is checked. If there are interrupt subprocesses 
waiting, the "ancestors" of the new current subprocess are scanned to see 
if any of them are interrupt subprocesses. To facilitate this scan, the 
first bit of the subprocess descriptor (see Figure 7) is, the "interrupt 
pending" flag. The interrupt datum is also stored in the subprocess 
descriptor. The "interrupt inhibit" flag (interrupt disarmed) in the 
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current subprocess. An interrupt subprocess call may also be initiated 
either when the "interrupt inhibit" flag is reset, or by the swapper, 
where a scan of the "ancestors" of the current subprocess is performed 
whenever the "interrupt" flag is set in P.ROllEAJJ (see Figure 3). 

TRANSFER OF CONTROL 

In general, there are six ways in which control can be transferred from 
one subprocess to another in the subprocess tree of a process. These may 
be grouped into two categories: 

!• Subprocess call or jump : a new entry is made on the call stack, 
the full path is recomputed, parameters of the call action are 
passed, and execution is initiated at the proper entry point of 
the called subprocess. There are three kinds of subprocess calls: 
normal , interrupt and error. (See Subprocesses : Subprocess Calls), 

2. Subprocess return : using an existing stack entry to obtain the 
new P-counter and the full path, the processing environment is 
reconstructed and control is returned to the subprocess. There 
are three kinds of subprocess returns : normal , F -return and 
forced F -return (see Subprocesses: Subprocess return). 
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SUBPROCESS 

Every process is constructed as a set of related subprocesses in order to 
permit dynamic control of the privileges and protection applied to the process. 
The envelope of protection/privilege associated with a process may change as 
the process executes, but all changes in protection can be seen as being syn- 
chronous with the process execution. It is only through a subprocess transfer 
that the envelope of protection/privilege is modified. 

SUBPROCESS DESCRIPTOR 

The data necessary to describe each subprocess is gathered into an eight 
word subprocess descriptor (see Figure 1) . The subprocess descriptors are 
stored together in the subprocess descriptor table in the variable length process 
descriptor (see Processes) . Each subprocess has a name by which it can be iden- 
tified and accessed. This subprocess name is a class code , the value of which 
is stored in the subprocess descriptor (word 1), In addition to its own name, 
each subprocess must maintain a link to its "father" in the subprocess tree 
(see Processes). This link is maintained in the descriptor (word 0) as a pointer 
to the parent subprocess. Process interrupt (words 0,4) and error handling in- 
formation (word 6) are also maintained in the subprocess descriptor. 

Associated with each subprocess is a local envelope of protection/privilege. 
The local C-list controls access to other objects within the system, while the 
subprocess map dictates the contents of the local address space . Information 
concerning the limits of the local address space (word 0) , identification of 
the local C-list (words 4,5) and the subprocess map (words 3,4) are maintained 
in the subprocess descriptor. 

The subprocess entry point (word 2) is the address, relative to the local 
address space, at which a normal subprocess call will initiate execution of the 
subprocess. The maximum allowable stack pointer (word 6) is used to avoid the 
filling of the process stack to such an extent that more privileged subprocesses 
(i.e., subprocesses nearer the root of the subprocess tree) cannot be called to 
rectify the situation or to handle errors. The sum of the lengths of the local 
C-lists and subprocess maps of all the subprocesses on the path to the root of 
the subprocess tree is maintained (word 2) to help compute the relative origins 
within the full map and full C-list of the calling subprocess during subprocess 
transfer operations. I'Mnally, the last word of the subprocess de.scriptor ia used 
to maintain a list of the maps which have been swapped into CM while the process 
is running on the CPU. 
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WORD Interrupt flag: interrupt pending for this subprocess 

mapin flag: set if map of subprocess has been swapped in 

RA origin of local address space (relative to process CM origin) 

RA + FL end of local address space 

Ptr to father: link to father in subprocess tree (relative to process 
CM origin) 

WORD 1 subprocess name: the class code used to identify the subprocess 

WORD 2 entry point : address relative to RA to begin execution on a normal 

subprocess call 

Map origin: sum of "# logical map entries" of all "ancestors" except self 

C-list origin: sum of "C-list length" of all "ancestors" except self 

WORD 3 comp buf size: number of words allocated for the compiled map buffer 

logical map ptr: pointer (relative to process CM origin) to logical 
map of subprocess 

compiled map ptr: pointer (relative to process CM origin) to compiled 
map buffer 

WORD 4 interrupt datum: interrupt parameter if interrupt flag set 

# logical map entries: number of swapping directives permitted in 

logical map 

C-list length: number of capabilities or "empties" in local C-list 
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WOFD 5 C— list u^i^ue "a^ne ^nd MOT l"de'«'- ide"*"^ ^^'' ■" = *■-■""• ^-^ Tr-.r-^i r—i-ic:*- 

WORD 6 ESM pointer: pointer (relative to process CM origin) of first error 

selection mask word 

max error class: maximum error class which is possible to recognize 
in ESM 

max stack pointer: maximum permissable stack pointer for the subprocesses 

to be called 

WORD 7 mapin list link: if maoin flaa is set then link to suhnrncpss \jhr«zf mar. 

is swapped in below this subprocess in CM. If this 
subprocess is at the end of the map chain; then zero. 
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The envelope of protection/privilege applied to a process is modified by 
switching control from one subprocess to another. Subprocess transfers fall 
into two categories: subprocess calls and subprocess returns. A subprocess 
call causes a new entry to be made on the call stack, the full path to be re- 
computed, parameters of the call to be passed, and execution to be initiated 
at the proper entry point of the subprocess. A subprocess return passes no 
parameters and draws the full path and P-counter from an existing stack entry. 
In each case, the processing environment must be reconstructed to reflect the 
new full C— list, full map, and full address space. This reconstruction requires 
the swapping of one or more subprocess maps, the re-building of the full C-list 
table (see Capabilities and C-lists), the fetching of a new local C-list and 
setting of the full address space limits. 

SUBPROCESS CALLS 

There are three kinds of subprocess calls. The normal subprocess call is 
initiated by calling on the system in the usual manner, using an operation (IPO) 
whose action is "subprocess call". A normal subprocess call may also be initiated 
as the result of F-return action under the control of a multi-ordered operation 
(see System Entry/Exit - Operation Interaction). 

'^^^ gJ^'^or subprocess call is initiated by the ECS system or by a user 
request and will call the closest "ancestor" of the current subprocess which 
has the proper error class selected in its error selection mask (ESM) (see 
Processes, Error Processing). Finally, an interrupt subprocess call is initiated 
whenever a subprocess which is an interrupt subprocess has priority over the 
current subprocess (see Processes, Process Interrupt). 

For all subprocess calls, a new stack entry is constructed and the new pro- 
cessing environment is established. The P-counter and last IP list address of 
the current subprocess are stored in the old top of the stack. Then cells and 
1 of the full address space are zeroed. These cells are used in the event of 
hardware aritli errors and to simulate SCOPE system calls. Next, the origins 
(relative to the new Local environment) of the address space, C-iist, and map of 
the calling subprocess are computed and stored in cells 2, 3, and 4 of the full 
address space. If the calling subprocess is not a member of the new full-path 
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(see Processes), then these cells are zeroed (see Figure 2). Following the 
relative origins of the caller's address space, C-list, and map, the parameters 
of the subprocess call are copied to succeeding words of the subprocess address 
space. 

For a normal call, the parameters of the call are first formatted in the 
actual parameter area (P.PARAM) of the process descriptor by the system entry 
mechanism. These parameters are drawn from the user's Input parameter list 

call (IPO). In addition, the system entry routine places the name (class code) 
of the called subprocess at P.PARAMC, the number of parameters at P.PARAMC - 1, 
and a bit string denoting the types of the parameters at F.PARAMC - 2. After 
establishing the correct processing environment for the called subprocess, the 
parameters are transfered, under the control of the parameter type bit mask, 
to the local address space and local C-list of the called subprocess. Datum 
parameters are simply copied to the next parameter cell in the local address 
space. Capability parameters are copied to successive positions in the local 
C-list and the index of the parameter in the local C-list is stored in the 
next parameter cell in the local address space. On completion of the parameter 
passing, execution is initiated at the entry point of the called subprocess. 

During all subprocess transfer operations, if the interrupt pending count 
(P.INTERR) is non-zero, the "ancestors" of the current subprocess are checked 
to see if any of them are "interrupt" subprocesses (word of subprocess des- 
criptor). If so, the subprocess transfer operation is terminated and an 
interrupt subprocess call is initiated. As part of the termination of the 
previous subprocess transfer operation, the "interrupted" flag is set in the 
stack entry corresponding to the subprocess that was to be executed (if F-return 
action was interrupted, the "forced F-return" flag is set in the stack instead 
of the "interrupted" flag). As with the other subprocess calls, the processing 
environment, a new stack entry, and the origins of the previous subprocess are 
constructed for the interrupt subprocess call. The interrupt datum from the 
subprocess descriptor (word 4) is stored in cell 5 of the new local address 
space, and the "interrupt inhibit" flag is set in the new stack entry. 

Finally, the interrupt subprocess is entered 2 words before the entry 
point specified in the subprocess descriptor. 
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An error subprocess call is initated by the ECS system or by user request. 
An error subprocess call passes as its parameters the error class and error 
number which describe the error causing the call. Also, the bit in the ESM of 
the error subprocess corresponding to the error class must be reset to avoid 
error loops (e.g. subprocess makes error - gets called as error subprocess - 
makes the same error - gets called as error subprocess - etc.). The entry to 
an error subprocess is one word before the normal entry point. 

SUBPROCESS RETURN 

Like the subprocess call, the subprocess return must construct a new 

re-activate a subprocess using information left in a stack entry . The full path 
recorded in the stack entry is sufficient to reconstruct the processing environ- 
ment. The P-counter from the stack entry, along with the "interrupt" flag, 
control where in the subprocess execution is initiated. The normal return 
requires the P-counter to be modified by the low order 18 bits of the CEJ 
instruction which originally caused control to pass to another subprocess (see 
System Entry/exit). If the "interrupted" flag is set, the P-counter is not 
to be modified. Finally, the "forced F-return" flag in the stack will cause the 
subprocess return routine to transfer to the F-return routine (see System Entry/ 
Exit - Operation Interaction). 
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CLASS CODES 

A Class code is a protected 60-blt datum by which a user may identify himself 
or some ECS system object. Within the ECS cyctem, class codes are used as the 
names of subprocesses (See SUBPROCESSES) ; in the future they will be used to 
identify users within the disk system and will be called access ke ys . 

The 60-bits of a class code are divided into two 30-bit parts (see Figure 1). 
The upper 30-bits constitute the "permanent part" and are assigned by the sys- 
tem when the class code is created. Once assigned, the permanent part cannot 
be altered. The low order ;3U-blts of a class code, called the "temporary part", 
are set by the user and may be altered by him any time. 

Since each class code occupies only one word, they are not allocated space of 
Lueir own in ECS, but instead each is kept in Lue second word of the capability 
which refers to the class code. Since the second word of the capability usually 
contains the unique name and MOT index for the object, this choice of location 
for the class code seems reasonable. 

There are two system actions connected with class codes: The first allows the 
user to obtain from the system a new class code. The system keeps a counter for 
generating the "permanent part" of a class code, and each time one is requested, 
the counter is incremented and a new and unique class code is generated. The 
second action allows the user to set the temporary part of a class code. He 
must already have a permanent part, the capability for which (with the proper option 
bit set) he supplies as the first parameter. The second parameter is the 30-bit 
datum which is to be inserted into the temporary part of the class code. The 
3rd parameter is a C-list index to return the updated class code. A class code 
is destroyed only when the capability is destroyed by being written over. 



Figure 1. Class Code 
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Maps 



Associated with each subprocess is a map which directs the swapping of the 
subprocess address space between central memory and ECS files. A map con- 
sists of a fixed length sequence of map entries each of which is either "empty" 
or contains a swapping directive . A swapping directive (see Figure 1) 
designates a contiguous portion of an ECS file, a CM address within the local 
addres s space of the subprocess, and whether or not that section of subprocess 
memory is read only (not to be swapped out) . 

When a subprocess is to be swapped into CM, each non-empty map entry is pro- 
cessed in sequence and a file read action is effectively performed to copy 
the section of the file designated by the swapping directive to the local 
address space of the subprocess starting at the designated CM address. When 
a subprocess is to be swapped out, only those swapping directives not marked 
as "read only" need be processed. Note that there is nothing to prevent 
several swapping directives from designating overlapping areas in CM or in a 
file. The results of overlapping swapping directives may be determined by 
j-c^aeuiuev j-ii^ i-ndi. cjwdpj-n/ owcujuUi. jji. ui_ess>e!D uut; map euLixes xn sequencxax oraer . 

To minimize the time spent in swapping maps in and out, the logical map 
(sequence of "empties" and swapping directives) is "compiled", or converted, 
to a form containing the absolute ECS address of the sections of ECS files 
referenced by the swapping directives (see Figure 2). Since one swapping 
directive may span several data blocks in a file, the size of the compiled 
form of the map will reflect the need for additional entries in the compiled 
map. Both the number of entries in the logical map and the number of words 
to be allotted for the compiled map are declared when the subprocess is created 
and may not be altered. 

The absolute ECS addresses in the compiled map are sensitive to changes in ECS 
due to garbage collection. Thus, the map must be re-compiled whenever a 
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garbage collection is in progress or has occurred since the last re-compilation. 
A word in ECS (GARBCNTj indicates whether or not a garbage collection is in 
progress and contains the number+l of garbage collections since system ini- 
tialization. Each compiled map contains, as a prefix, the count of garbage 
collections at the time the map was last compiled. This count is compared 
with GARBCNT whenever the compiled map is about to be "executed" and will 
cause a recompilation if the counts are unequal. A recompilation of a map 
may be forced by setting the count In the compiled map prefix to zero. 

Access to both the logical and the compiled forms of the map is through the 
subprocess descriptor (see Fig. 3). The subprocess descriptor also contains 
the number of entries in the logical maps and the size of the buffer allocated 
for the compiled map. In addition, the subprocess descriptor contains a flag 
indicating whether the map for that subprocess has been swapped into CM and a 
chain pointer used to keep track of which subprocess maps are in CM. The 
origin (relative to Bl , the CM process origin) of the subprocess address space 
(RA) and the origin + length (RA + FL) of the subprocess address space are also 
available to the map machinery in the subprocess descriptor. 

The maps of the subprocesses in the full path are concatenated to form the full 
map in much the same way as the full C-list (see C-list) is formed. Each map 
however, is swapped relative to the address space of its subprocess, as if it 
were the only map being considered. The address space of the running subprocess 
is enlarged to form the full address space , which includes the address space (s) 
of all other subprocesses in the full path. The code and data in the maps above 
(in the full path) the running subprocesses may be accessed as if the address 
spaces of the other subprocesses were simply added (one after another) onto the 
end of the local address space of running subprocess. Note, however, that the 
data and code within these maps is not relocated to reflect the new addresses 
used to access them. 
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i'iap Actxotitj 

I^hen map entries are to be changed, care must be taken when the map involved 
is part of the full map. In this case, if the map entry involved is not 
empty, it must be swapped out before it can be replaced. The new entry 
(if there is one) can then be constructed and swapped in. Note that overlapping 
map entries will behave oddly since the portions swapped under one map entry 
may be partially or completely overwritten by the area swapped under a sub- 
sequent map entry. At the present tim^ the entire map is recompiled, since 
a change in the logical map may change the length of the compiled map. Incre- 
mental compilation is not precluded by the design since the logical map con- 
tains pointers into the compiled map; however, the implementation of this 
feature has been deferred. 

Direct User ECS Access 

To allow the user an ECS RA and FL, so that he may access directly an often 
used segment of ECS, the current subprocess is permitted to have one direct 
ECS access map entry. If present, it must always be the first map entry, and 
may reference only one file block (due to physical limitations). 

The Direct Access Entry (DAE) is implemented as a regular map entry (as far 
as the map compiler is concerned) except that the CM address part is always 
zero and the DAE flag bit (appearing only in the first map entry) is set. 
Two special ECS system actions are available to set/clear the DAE flag bit. 
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Figure 1 Logical Map 
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Figure 2 COMPILED MAP 
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SUBPRQCESS DESCRIPTOR (MAP DATA) 
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EVENT CHANNELS 

Event Channels are ECS system objects used to synchronize running pro- 
cesses as well as to implement "block" and "wake up" mechanisms. Basically, 
a user process may request an event from a particular event channel. If the 
event channel does not have an event, the user's process is blocked (stops 
running) until some other process sends an event to the event channel. The 
exact mechanisms of sending and receiving events will be described in full 
detail . 

The event channel (see Figure 1) consists of a three word header followed 
by the event queue. The event queue is a circular buffer controlled by pointers 
and values located in the first and third header words. 

First header word: The "in" and "out" pointers in the first word are 
manipulated to point relative to tlie beginning of the event channel. The 
"in" pointer always points to the location in which an event is to be put 
should one arrive. The "out" pointer points to the location of the next 
event to be removed from the event queue. The "in" pointer will equal the 
"out" pointer when the event queue is either empty or full. Therefore, the 
number of empty places in the circular buffer is maintained in the third 
header word. Finally, the length of the entire event channel is recorded in 
the first header word. 

Second header word: The second header word is used to maintain a queue 
of waiting processes. When a process requests an event and the event queue 
is empty, the process is added to the process queue. The process queue is a 
bi-directional list through the processes on the queue and the event channel 
(see Figure 2). The high order 30 bits of the second word of the header, called 
the process queuing word , hold the forward pointer while the low order 30 bits 
hold the backward pointer. Each pointer consists of a Master Object Table (MOT) 
index and a queuing word index. The queuing word index, in the high order 12 
bits of the pointer, is an index relative to the beginning (in ECS) of the process 
which is designated by the MOT index of the low order 18 bits of the pointer. 
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within the process, aL Liie iocatioii iaaicatea uy tiie queuing word index, 
there should be another process queuing word with forward and backward 
pointers. The queuing word index is stored in such a way that the unpack 
(UXi Bj ,Xk) instruction will result in the true queuing word index in the 
B register. Furthermore, if the pointer refers to the event channel, the 
queuing word index will unpack to a -2 in the B register. For example, 
the pointer: 206lo |000123o refers to the 61„-st word (in KCS) of the process 
with MOT index 123^. Similarly the pointer: 1775„j 00321 refers to the pro- 
cess queuing word of the event channel with MOT index 321„. If the process 

o 

queue is empty, the process queuing word in the event channel will point to 
the event channel itself (e.g., (1775g | 000321g | 1775g |000321g) ). 

Event Channel Routines 

It is important to note before discussing the event channel routines that 
they are one of the few places in which there is interaction between the ECS 
action routines and the interrupt system. Since the interrupt system may 
call upon the event channel routines at any time, it is necessary to lock 
out the interrupt system while manipulating event channels and to release the 
lockout upon completion of any event channel manipulations. To lock out the 
interrupt system, it is only necessary to set I. LOCK (in system core) non- 
zero. To release the lock, simply clear I. LOCK. 

Sending Events 

Events are sent by user processes and by the interrupt system. An event 
consists of two words. The first word is the MOT index of the process which 
is sending the event. The second word is a 60 bit datum provided by the sender 
of the event. A response is always given to the sender of the event to indi- 
cate the disposition of the event (^see Figure 3). For a user process, the 
response is returned in X6. 

If the event queue of the appropriate event channel is not empty, then 
it may or may not be searched for an event duplicating the new event. This 
is to allow for the elimination of redundant events. If the event queue 
search was desired and if a duplicate event is found, a response is given to 
the sender indicating that a duplicate event was discovered, and the event 
sending routine returns. 
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If no duplicate event checking was requested or no duplicate event was 
found, the event queue is checked to see if it has more than one empty slot. 
If the event queue is full, the sender of the event is notified that the queue 
is full, and control returns to the sender of the event. If there is only 
one slot left in the event queue, the datum word is replaced by a special 
"you lose" datum (-0) and the sender is notified by the "you lose" response. 
This "you lose" datum allows fhp nrnr-oao T.TVn-^v, ,,i ♦--.•^^..^i.. .•„_„ ., . .i 

lose" event to discover that the event queue had been full and that informa- 
tion was lost. 

If the event survives the duplicate event checking and the full event 
queue conditions, it is copied into the event queue and the pointers are moved 
to reflect its presence. Again, the sender of the event is notified of the 
deposition of the event. 

If the event queue is empty, the process queue must be checked. (Note 
that if the event queue is not empty, then the process queue must be empty.) 
The process queue is scanned for the first process which does not have its 
"wake-up waiting" flag set, i.e., has not already been handed an event, received 
a process interrupt, or been marked for destruction. If such a process is 
found, and it is not a pseudo process (used by interrupt system to interface 
with the event channel logic and other purposes), the "wake-up waiting" flag 
is set on that process.' The P counter in the process exchange package is incre- 
mented and the event is copied to X6 and X? of the process exchange package in 
ECS. Note that the testing and setting of the "wake-up waiting" flag must not 
be interrupted by any other access to this flag. If the process is not running 
("running" flag) the scheduler is called to schedule the process to run. If the 
first process without "wake-up waiting" is a pseudo process, it is removed from 
the process queue; otherwise, it is not removed until the process is swapped in 
to run. Also, in the case of a pseudo process, the event channel routines return 
to UNHUNGl in the interrupt system. 

Finally, the "running", "event", and "pending action" flags are set in 
the process. The "pending action" flag, the "event" flag, and the "wake-up 
waiting" flag are used to control the swapper and the routines for hanging a 
process on several event channels, process interrupt, and process destruction. 

If the process queue is empty or has no processes without "wake-up 
waiting", and the event queue is empty, the event is copied to the event 
queue and the appropriate response is passed to the sender. 
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A user process may attempt to get an event from an event channel. If the 
event queue is empty, the process may wait ("hang" or "block") until an event 
arrives before resuming execution. Also, a process may attempt to get an event 
from any one of a set of event channels and, in the absence of any events, the 
process may discontinue execution ("hang" or "block") until an event arrives 
for one of the event channels. If more than one process is awaiting an event on 
a single event channel, the first event to be set to that channel is passed to the 
first process while the other process (es) continue to wait. 

The mechanism of getting an event or hanging (waiting for an event to 
arrive) begins with a check on the event queue of the event channel. If the 
event queue is non-empty, the head of the event queue is removed and the 
event is passed to the process (in X6 and X7 for a user process). 

If the event queue is empty the process must be added to the queue of 
waiting processes (process queue) using a process queueing word in the ECS 
image of the process. The "running" flag in the process is cleared and the 
process is removed from the scheduling queue (de-scheduled). Next, the P- 
counter of the process is decremented by one. This is to allow for the possi- 
bility of a process interrupt causing the process to resume execution. In this 
case, when the interrupt subprocess returns, the process will re-execute the 
exchange jump, which calls the system to try to get an event from the event 
channel. When the process has been chained on the process queue, the system 
and user clocks are updated and the event channel routines exit to SWAPOUT in 
the swapper to swap out the process . 

When an event arrives for a process which is hung on an event channel, 
the event sending mechanism will set the appropriate flags and schedule the 
process to run as described above. The swapper will detect the "event" flag 
and return through SYSRET instead of TOUSER of the system entry/exit routines. 
The swapper will have already removed the process from any process queues on 
which it had been hung. 
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routines must interrogate the event channels one at a time. If an event 

channel has an empty event queue, the process is queued in the process 

queue of that event channel using the next queuing word of the process. The 

sequence of "in use" queuing words in the process must be terminated by a 

zero word. Between the interrogation of event channels, the "wake-up waiting" 

flag is checked. If this flag is set, an event has arrived on one of the 

event channels which has already been interrogated. If an event has arrived 

or an event is discovered on an event queue of an event channel, the process 

is removed from all the process queues on which it is already chained, and the 

event channel routines exit to the system entry/entry mechanism. When -iTiterrogating 

the set of event channels periodic pauses must be made to allow the interrupt 

system to run. Otherwise, the interrupt system might be locked out for an 

intolerably long time. If, after interrogating the last event channel, the 

"wake-up waiting" flag is not set (note that the interrupt system is still 

locked out), the process is descheduled, the P-counter is decremented, and 

the event channel routines exit to SWAPOUT in the swapper. 
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Figure 3 
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TIME SHARING SYSTEM TEXT STANDARD 



The System Standard Text (Systext) is the standard method of storing coded 
information for the Time Sharing System. Information in Systext format exists 
in a file (a aemi- infinite array of 60-bit words) and is terminated by an end- 
of-information word. A Systext file is composed ot lines , which contain 
character coded information, and segments which contain no information and 
are called sloppy segments . 

Systext Lines 

A line is a sequence of 7 bit ASCII characters terminated by the control 
character CR (= 155g). There is no limit to the length of a line and they 
may be split across file block boundaries. Each line is packed left-justified 
into successive 60-bit words, 8 characters (56 bits) per word. The first 4 
bits of each word serve to signal the beginning of a line: for the first word 
of a line these leading bits are 1001; for all other words in a line they are 
0000. Consider the line ABCDEFGHIJ CR which would be stored in Systext as: 



1001 A 


B 


C 


D 


E 


F 


G 


H 



0000 


I 


J 


CR 


* 


A 


* 


* 


* 



Characters which follow the appearance of CR in a word are ignored. 

Multiple blanks in a line are compressed by inserting a count of the number 
of blanks rather than the blanks themselves. The ASCII character ESC (=173 ) 
is reserved for this purpose. Wlienever ESC occurs in the Systext file, the 
character following it is interpreted as a blank count, 'n' (0 <. n < 128 ) . 
On output these two characters are replaced by n blank characters. 



Character Representation 

The internal ASCII code used in System Standard Text is the external ASCII + 
140g (mod 200g). The conversion is performed by the system I/O routines (see 
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This scheme maps blank onto 0, onto 20„ and A onto 41„ 



p. 73). 

See Table 1. Non- graphic characters, however, are not allowed to occur in 
System Standard Text. (CR and ESC in the contexts described above are 
the only exceptions.) Therefore, the character % has been reserved as a 
special prefix for representing non-graphic characters; if the graphic fol- 
lowing a % maps onto a control character under the mapping: internal 
ASCII + lOOg (mod 200^), the pair is interpreted as that control character 
(see Table 2). Otherwise the % leaves its successor unchanged. So 
%2 reoresents 2 and TM renrespnts CM 



Sloppy Segments 

A sloppy segment in the Systext file is a group of n words (0 < n < 2^^) 
that are to be ignored. The first and last word of such a segment is of the form; 
-INDEF 



6000 
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47 



18 



where n is the count of words in the segment. The system ignores the 

middle 30 bits of this header word and the succeeding n-1 words. A sloppy 

segment may not occur within a line and cannot be split across file block boundaries. 

End-of -information 

The end of Systext is signaled by an end-of-information (EOI) word of the 
form: 



4000 





59 47 
The low order 48 bits of the word are ignored, 
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Graphic TTY Character Representation 

CDC CDC 

Internal ASCII Printer Internal ASCII Printer 

TTY Character Representation Character TTY Character Representation Character 

14 t^ R 62 R 

IV S 63 S 

2 4- T 64 T 

^/ 3 = U 65 u 



$ 4 $ V 66 V 

% 5 % W 67 w 

X 
Y 



& 6 '^ X 70 

7 ?t Y 71 



( 10 r Z 72 

) 11 ) [ 73 [ 

* 12 * \ 74 p^ 

+ 13 + ] 75 1 

14 , i 76 + 

15 _ ^ 77 -^ 

16 . ' 100 ^ 

A 
B 



D 
£ 



/ 17 / a 101 

20 b 102 

1 21 1 c 103 

2 22 2 d 104 

3 23 3 e 105 

4 24 4 f 106 i, 

5 25 5 g 107 G 

6 26 6 h 110 H 

7 27 7 i 111 I 

8 30 8 j 112 J 

9 31 9 k 113 K 
: 32 : 1 114 L 
5 33 ; m 115 ^ 
< 34 < n 116 N 
= 35 = o 117 
> 36 > p 120 p 
? 37 > q 121 Q 
e 40 < r 122 R 
A 41 A s 123 S 
B 42 B t 124 T 
C 43 c u 125 u 
D 44 D V 126 V 
E 45 E w 127 w 
F 46 F X 130 X 
G 47 G y 131 Y 
H 50 H z 132 z 
1 51 1 { 133 ( 
J 52 J I 134 

^ 53 K X 

L 54 L ^ 135 ) 

M 55 M ~ 136 )/ 

N 56 N rubout 137 -^ 

57 

P 60 p 

Q 61 Q 



Character 


Representation 


NUL 


140 


SOH 


141 


STX 


142 


ETX 


143 


EOT 


144 


EN 


145 


KCV 


146 


BEL 


147 


BS 


150 


HT 


151 


LF 


152 


VT 


153 


FF 


154 


CR 


155 


SO 


156 


SI 


157 


DLE 


160 


DCl 


161 


DC 2 


162 


DC 3 


163 


DC4 


164 


NAK 


165 


SYN 


166 


ETB 


167 


CAN 


170 


EM 


171 


SUB 


172 


ESC 


173 


FS 


174 


OS 


175 


RS 


176 


US 


177 
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Table 2 
Non -Craphlc TTY Character Representation 

Internal ASCII Key Combination 

Systext Representation Function 

% (a 

% A 

% B 

% C 

% D 

% E 

"/ T? 

to i- 

% G Bell 

% H Backspace 

% I Horizontal Tab 

% J Line Feed 

% K Vertical Tab 

% L Page Eject 

% M 

% N 

% 

% P 

% Q 

% R 

% S 

% T 

1 U 

% V 

% w 

% X Delete Line 

% Y 
% Z 
% [ 
% \ 

% ] 
% + 
% ^- 
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THE LINE COLLECTOR 

The line collector collects a line from the TTY using the previously typed 
line as a template. It maintains two lines simultaneously, an old one and 
a new one. The old line is the last line received by the Teletype (or 
from INITIAL) and is local to the virtual TTY buffer; it may possibly be 
empty. A new line is constructed from the old one using the characters 
typed in from the Teletype. To visualize the process of constructing each 
new line, imagine two cursors or pointers, one called OLD which runs over 
the old line and one called NEW which is positioned on the new line as it 
is created. Normally when a character is entered from the TTY, it is 
appended to the new line and both cursors advance on place. If certain non- 
graphic characters, called Control Characters (see Table 3) are entered, 
the cursors can be manipulated so that, for example, characters are COPIED 
from the old line to the new one, or parts of the old line are SKIPped, or 
the cursors BACKUP over undesired characters. 

The most obvious application for the line collector would be in conjunction 
with an on-line compiler which performs a simple syntax check of each line 
as it is entered. If the line is bad it output a diagnostic, rejects the 
line, and calls on the line collector. The user edits the old line which 
still resides in the virtual buffer and resubmits it to the compiler. 
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The line collector permits the following actions to be performed via the 
appropriate control characters ; 



Operation 
Accept 



Type State 



Control Characters 




'CTRL j ^HIFT) { \ ') 



Concatenate and 
Accept 



Concatenate, Print (CTRL 



and Accept 



Tab Set/Release 




Tab 



Insert Change: 



CTRL) (^ 





Action 

The current new line is accepted 
as is . 

Advances the printed paper to a 
fresh line . Spaces to the current 
position of the New cursor, prints 
a copy of the remainder of the old 
line, and on the following line prints 
a copy Ox tae new line u^ Lu Lhe cur- 
rent position of the cursor. 

e.g.: remainder of old line 

current new line 
i 
(New cursor) 

Concatenates the remainder of old 
line onto the current new line and 
accept. 

Concatenates the rest of the old 
line onto the new line, prints 
it out, and accepts. 

current position of the cursor in 
the new line if entered an odd 
(even) number of times . 



ad- 



Inserts blanks up (both cursors 
vance) to the next tab stop. 

If entered an odd number of times 
since the beginning of the first line, 
the cursor in the old line is not 
moved on Backup or normal entry 
operations, thereby allowing the 
insertion of characters into a line. 
Odd numbered entries of the control 
characters are echoed by < . 
Even numbered entries return the 
cursor to its normal action and 
are echoed by > . 






If the first key specified is (cTRl) , the second key must be pressed 
while the first key is still depressed. 
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re-edit 




Lj u c:: v> J. u. a- 






Wlw/lH^dLdlCl UC new iXllC WXLLl J. CILICL J. liuci: 1. 

of old line and make the concatena- 
tion the old line, positioning the 
cursor at its beginning. 



Identical to (CR) except that the 
line collector notifies the calling 
routine that this line is special. 
(Can bemused to switch modes, i.e., 
to leave "append mode" in the 
Editor.) 



Panic 



/ctrl\ 

(SHIF^ 




Interpreted by the PP, this command 
sends an interrupt to the process. 
May be used to get a process out of 
a loop or to get its attention. 



For each of the three actions Backup, Copy, and Skip, the distance can be 
specified in 6 ways (see Table 3) . In the descriptions which follow, a word 
is defined as a sequence of one or more non-alphanumeric characters delimited 
by non-alphanumerics; when looking for the beginning of a word, the cursor 
passes over all non-alphanumerics until it encounters one or more consecutive 
alphanumerics. Next character entered refers to the first occurrence in the 
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4-1 4-»._1 „u„-».. 



T^ ^t- „^, 



time an edit request is made which cannot be fulfilled, the line collector 
echoes a bell Instead of the graphic specified. 



Operation 



Backup one 
character 



Backup one 
word 



Backup to next 
character entered 



Backup to and 
including next 
character entered 



Backup to tab 



Backup to edge 



Control Characters 



Copy one 
character 



Copy one 
word 




fcTRL) 



/WRU\ 






00 

©f xoff\ 
I c / 



Copy up to next i qjj^l 
character entered V / V D 




Action 



Cursor in the new line backs up 
(erases) one character'? ^ is 
echoed on the printer. 

Cursor in the new line backs up 
(erases) one word* -<- is echoed 

Cursor in the new line backs up 
(erases) up to but not including 
the new character entered'!' -*- 
is echoed on the printer. 

Cursor in the new line backs up 
(erases) up to and including the 
next character entered'? -^ is 
echoed on the printer. 

Cursor in the new line backs up 
(erases) up to the preceding tab 
setting* -*- is echoed on the line 
printer. 

Cursor in the new line backs up 
(erases) up to the left edge, thereby 
starting the line anew? ^ is 
echoed on the line printer. 

The next character in the old line 
is appended to the new line, and 
the character is printed. 

The next word in the old line is 
appended to the new line and is 
printed. 

Characters in the old line up to 
but not including the next character 
entered are appended to the new line 
and printed. 



The old cursor moves simultaneously with the new cursor, 
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Copy up to and 
including next 
character entered 



Copy to tab 



rnnv rpst nf 




old line 




Skip one 
character 



Skip one word 




Skip to next (^^ ^ ^ 
character entered V / ^ 



Skip up to and 
including next 
character entered 




Skip to tab 




Skip to end 
of line 




Characters in the old line up to 
and including the next character 
entered are appended to the new 
line and printed . 

Characters in the old line up to 
the next tab setting are appended 
to the new line and printed. 

The remainder of the old line Is 
appended to the new line and printed, 



IS equi- 




ove , 



valent to /cTRl\ (Zj ab 

Cursor in the old line moves ahead 
(skips) one character* $ is echoed 
on the printer. 

Cursor in the old line moves ahead 
(skips) one word* $ is printed 
for each character skipped. 

Cursor in the old line moves ahead 
(skips) to but not including the 
next character entered* $ is printed 
for each character skipped. 

Cursor in the old line moves ahead 
(skips) to the position immediately 
after the next character entered.* 
$ is printed for each character 
skipped. 

Cursor in the old line moves ahead 
(skips) to the next tab setting.* 
$ is printed for each character 
skipped. 

Cursor in the old line moves ahead 
(skips) to the end of the line* $ 
is printed for each character skipped. 



The cursor on the new line moves simultaneously with the cursor on the 
old line. 
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TalQ-h\/no T /O Fijnrt-T nine 
— " — -^ ■ — ~' ~ - . - ■-- 

The TS System l/O functions are a set of reentrant routines which should be 
loaded into a continuous section of core. If absolute images are used, they 
must reside in the riglit part of core. To initialize these functions, one 
jumps to .TTY. ON with 



Bl set to the base of a 133o CM word data area (TTYBUFF) for 

o 

this teletype. 

B2 set to the index in the C-list for the TTY file. 

(B2)+l is the index of the CP to PP event channel 
(B2)+2 is the index of the PP to CP event channel. 

X7 is set to the return address in calling program. 



I/O operations are performed upon strings or lines where a string is a sequence 
of characters and a line is a string terminated by a CR character. Every 
string or line is quantified by a two word entity called a string descriptor . 
The first word of a string descriptor points to the word base address of a given 
string; the second word indicates the length of the string, or for a line, 
the upper bound on the length, since the terminating CR character signals 
the end of a line. 

Output 

To output a string described by the string descriptor DESC, DESC+1 the following 
macro call is invoked : 

.PUTOUT 

The data area for the TTY 



MACRO 


TTYBUFF , 


DESC 


SBl 


TTYBUFF 




SA4 


DESC+1 




SX7 


*+l 




JP 


PUTL 




ENDM 


.PUTOUT 





.PUTOUT outputs characters up to and including a CR or until the length spe- 
cified in the second word of the descriptor is exceeded, whichever occurs first, 
Lines with blanks compressed as well as uncompressed lines may be output by 
.PUTOUT. If a CR is encountered, a LF is also echoed. 

NOTE: If the flag at TTYBUFF + FORCE (FORCE = 23g) in the TTY data area is up, 
the TTY buffer will be flushed (PP is notified that there is something in the 
buffer) each time .PUTOUT finishes. This kind of call-by-call flushing 
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is expensive and should be suppressed when possible. Therefore, if a large 
file is to be listed, the FORCE flag should be turned off until the last line. 
With the flag off, lines will be forced out only when the TTY buffer becomes 
full. Initialization leaves FORCE up. 

A single character is output when a macro call to .OUTPUTC is invoked: 

THAR 



OUTPUTC 


MACRO 


TTYBUFF , 




SBl 


TTYBUFF 




SXl 


CHAR 


+ 


SB7 


■k+l 




JP 


PUTCTTYT 




ENDM 


. OUTPUTC 



The output buffer is flushed when a macro call to FLUSH is invoked; 
FLUSH 
+ 



MCRO 


TTYBUFF 


SBl 


TTYBUFF 


SB7 


*+l 


JP 


FLUSH 


ENDM 


FLUSH 



Input 

Teletype input is significantly more complex than output. The routine 
INGET is called to get a line from the TTY: 



INGET 


MACRO 


TTYBUFF 




SBl 


TTYBUFF 


+ 


SX7 


*+l 




JP 


GETL 




ENDM 


TTYBUFF 



INGET causes a new line to appear as the string described by the string 
descriptor stored at TTYBUFF + NEW (NEW = 101„). This new line does not 

o 

yet have blanks compressed and the first four bits of each word are zeros. 

INGET obtains the new line from the teletype using the line described by the 
descriptor TTYBUFF + OLD (OLD = 76g) as a template. To modify the template 
merely Involves updat Lng the OLD descriptor and its image with desired new line. 
The line must not exceed 86 characters in length since tliat is the maximum 
length of a line which INGET can return. 
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A call to the following macro enables the user to detect the reserved 
control character % U . 

INGET. 



+ 



MACRO 


TTYBUF, COMMAND 


SBl 


TTYBUF 


SX7 


COMMAND 


LX7 


18 


SX6 


*+2 


BX7 


X6+X7 


JP 


GETL 


ENDM 


INGET . 



It tae line gotten rrom tne TIY Durter is terminatea Dy 'A U instead of CR , 
then control returns to COMMAND rather than *+l . This allows the TTY to 
earmark certain lines as special. For instance, consider a file editor which 
allows lines to be appended to a file. There must be a way for the user to 
signal which line is the last line to be appended to the file. However, every 
key has a pre-assigned meaning or can appear in a line; the only exception is 
% U . Thus the editor could designate % U to terminate the last line of the file 
and control will return to COMMAND. 

The input buffer can be cleared (the contents are removed and discarded) by a 
macro call to CLEAR: 



CLEAR 


MACRO 






SBl 


TTYBUF 


+ 


SB7 


■k+l 




JP 


.CLEAR 




ENDM 


CLEAR 



Since these routines should suffice for most circumstances, the following 
esoteric features can be ignored by the majority of users. 

The routine GETS concatenates characters up to and including the next break 
character (see p. 4) onto the string described by the string descriptor DESC. 

All but the break character are echoed; the break character is returned in XI, 
GETS is called as follows: 

GETS 



+ 



MACRO 


TTY, DESC 


SBl 


TTY 


SA4 


DESC+1 


SB6 


1 


SX7 


*+l 


JP 


GETS 


ENDM 


GETS 
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There is one anomoly connected with GETS; if no check were provided, it would 
be possible for GETS to accept a string that was long enough to clobber storage 
when it was concatenated cnto the string described by DESC. To avoid this, 
GETS expects DESC+2 to contain an upper bound on the length of the resulting 
string. If GETS receives a string which when concatenated would exceed this 
upper bound, it returns in X.CHAR the negative of the first character in 
the string which causes the bound to be exceeded. 

The routine GETCTTY gets the nejct character from the TTY buffer placing it in 
XI; it is called as follows: 



GETCTTY 


MACRO 


TTYEUF 




SBl 


1 


+ 


SB7 


*+l 




JP 


GETCTTY 




ENDM 


GETCTTY 



GETCTTY does not echo the retrieved character even if the SOFTECHO (= ll^) 

o 

flag in TTYBUFF is on. (The SOFTECHO flag signals that the PP has not been 
able to echo a character and therefore that GETS should.) 



The macro call to NE\'JBREAK is used to switch from nne table of break characters 
to another. 



NEWBREAK 


MACRO 


TTYBUFF , I 




SBl 


TTYBUFF 




SB2 


I 


+ 


SB7 


*+l 




JP 


NEWBREAK 




ENDM 


NEWBREAK 



If the break table is switched, it should be restored to break table #2 before 
using GETL. Other routines will work with any break table. 

Table Number Characters which signal a break 

none 

1 any character 

2 non-graphics 

3 non-alphanumerics 

4 non-numerics 



